Field of the Disclosure
The present application relates generally to the field of cloud computing and, specifically, to the optimization of task processing in a heterogeneous cloud computing environment.
Description of Related Art
In the prior art, batch computing services are distributed cloud services utilized for processing massively parallel batch processing jobs. These services are used relatively widely in the fields of film and animation rendering, biological data analysis, multimedia transcoding, finance, insurance analysis, and similar fields requiring high volume, parallel computing.
Users of batch computing services may define a specific computing need as a job, with a job containing multiple independent or dependent tasks. Furthermore, each task may have one or more execution instances and may specify a running program address, an input/output path (i.e., an input/output address of the data required for running a program), resource needs (CPU and memory), and concurrency needs (e.g., specifying the quantity of instances contained in each task).
In batch computing models, even though one may be dealing with massive concurrency scenarios (e.g., concurrency node levels in the hundreds or thousands), users' descriptions of resources are generally homogenous (e.g., single resource descriptions, that is, all instances of each task use computing resources with the same configuration), and it is difficult to adapt to heterogeneous massive cloud computing resources.
In the process of constructing a cloud computing resource, factors such as cost considerations, reuse of old equipment, different purchase batches, etc., often result in a large number of heterogeneous computing resources (including inconsistent machine models, CPUs, memory, and the like) being used to provide cloud computing services. When heterogeneous computing resources are used for massively parallel batch computing, generally only single resource specifications (including the number of CPU cores and memory size) can be used to allocate computing resources, which can cause computing resources to be underutilized.
For example, consider a heterogeneous cloud computing cluster that includes 100 16-core, 100 24-core, 100 32-core, and 100 48-core CPU computing resources. When a user executes a job on this cluster, generally only 14-core CPUs may be specified for each instance (the other two cores being reserved for system overhead) because higher configuration resources, such as 24-core, 32-core or 48-core CPUs, may cause greater waste. That is, a user may choose to use a 14-core CPU for each instance in order to use as many computing nodes as possible, as explained below.
For example, all 400 computing resources may be used if the user uses 14-core CPUs for computing, since larger capacity resources are capable of handling the user's 14-core request. Conversely, only 200 computing resources can be used if the user uses 30-core CPUs for computing (e.g., only the 100 32-core resources and 100 48-core resources). Additionally, if the user requests 14-core CPUs for computing, when a user's job is executed, no matter what the actual configuration of the computing resources is, only the 14 cores of the CPUs can be called for executing the user's job, and the other resources (e.g., cores) will be idle.
In order to solve this problem in the prior art, two possible prior art methods have been implemented. In a first method, a user is asked to split a single job or task into multiple different jobs or tasks, respectively, and different resource needs are defined for each split job or task to adapt to the heterogeneous cloud computing resource. In a second method, support for multiple virtual machines is added to the heterogeneous cloud computing resource in order to improve the resource utilization ratio. Both attempt to solve, to a certain extent, the problem of underutilization of the heterogeneous cloud computing resources, but they both have the significant deficiencies.
In the first method, the user is required to split jobs according to different resource needs, which is relatively difficult in practice. This is because the specific allocation of heterogeneous cloud computing resources is invisible to the user, so the user is unable to know how many resources can be allocated to computing resources (e.g., above 14-cores, above 22-cores etc.). Therefore, this method is significantly complex, low in operating efficiency, and unfriendly to the user.
In the second method, support for multiple virtual machines is added. This method may better improve the utilization ratio of the heterogeneous cloud computing resources, but can only support a limited number of specific user scenarios. For example, when a user's job is a network I/O-intensive job, supporting multiple virtual machines on a single physical machine may cause inefficient network competition between virtual machines and cause the decline of the overall performance in processing the user's job.
No effective solution has yet been put forward to address these problems in the prior art that when batch computing is conducted using heterogeneous cloud computing resources, the heterogeneous cloud computing resource is underutilized, which results in a low efficiency in processing tasks contained in a user's job.